Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-101

Text File | 1995-12-31 | 94KB | 2,571 lines

C.S.M.P. Digest             Wed, 21 Jun 95       Volume 3 : Issue 101

Today's Topics:

        Checking for weak-linked CFM libraries
        Copying files across volumes?
        Creating alias files
        Design flaw of the Drag Manager?
        How to do a time-to-finnish bar...
        How to get TCP-IP address?
        PICS file format?
        PPC and SIZE resource
        Pausing SndPlayDoubleBuffer
        QD3d in develop 22
        QuickDraw 3D Database for Toolbox Assistant now available!
        Techniques for collision detection
        What is the Finder trying to tell me?
        Why is the Prefererred Executable Format a big secret?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Jim Matthews)
Subject: Checking for weak-linked CFM libraries
Date: Mon, 29 May 1995 14:33:39 -0500
Organization: Dartmouth College

I've seen the answer to this, but for the life of me I can't find it, so
hopefully someone out there has it handy....

I want to check at runtime whether a weak-linked CFM library (specifically
ObjectSupportLib) is present, so that I can let users run my app (sans
Apple Event Object capabilities) without having to find and install the
library.  I know that theres a simple one-line test, but my scan of
relevant documentation and sample code hasn't turned it up.

Thanks,

Jim Matthews
Dartmouth Software Development
<http://www.dartmouth.edu/pages/softdev/>

+++++++++++++++++++++++++++

>From [e-mail] (Jim Matthews)
Date: Mon, 29 May 1995 15:14:27 -0500
Organization: Dartmouth College

In article <[e-mail]>,
[e-mail] (Jim Matthews) wrote:

> I want to check at runtime whether a weak-linked CFM library (specifically
> ObjectSupportLib) is present, so that I can let users run my app (sans
> Apple Event Object capabilities) without having to find and install the
> library.  I know that theres a simple one-line test, but my scan of
> relevant documentation and sample code hasn't turned it up.

Of course, within an hour of posting this I happened to pick up develop 21
and see the same question in the Q & A section.  The answer is to compare
a symbol from the library with kUnresolvedSymbolAddress.  So the
expression:

        AEObjectInit != kUnresolvedSymbolAddress

returns true if ObjectSupportLib is available, and false otherwise.

Jim Matthews
Dartmouth Software Development
<http://www.dartmouth.edu/pages/softdev/>

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Wed, 31 May 1995 21:12:53 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Jim Matthews) wrote:

> I've seen the answer to this, but for the life of me I can't find it, so
> hopefully someone out there has it handy....
>
> I want to check at runtime whether a weak-linked CFM library (specifically
> ObjectSupportLib) is present, so that I can let users run my app (sans
> Apple Event Object capabilities) without having to find and install the
> library.  I know that theres a simple one-line test, but my scan of
> relevant documentation and sample code hasn't turned it up.

  if( ! NameofAKnownFunctionInTheCFMLibrary )
      printf("Bummer");


--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Thu, 01 Jun 1995 01:23:31 -0800
Organization: Altura Software, Inc.

> I've seen the answer to this, but for the life of me I can't find it, so
> hopefully someone out there has it handy....
>
> I want to check at runtime whether a weak-linked CFM library (specifically
> ObjectSupportLib) is present, so that I can let users run my app (sans
> Apple Event Object capabilities) without having to find and install the
> library.  I know that theres a simple one-line test, but my scan of
> relevant documentation and sample code hasn't turned it up.

I belive you can simply try to FindSymbol on something you know is in the
library.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Who is John Galt?

---------------------------

>From [e-mail] (Harry Hahn)
Subject: Copying files across volumes?
Date: Sun, 04 Jun 1995 01:46:55 -0500
Organization: Univ. of Wisconsin- Madison

How does one copy a file from one volume to another? It looks like none of
the FS calls work across volumes and though PBHCopyFile looked like the
ticket, I get a -50 error (paramError-function not supported by volume).

I've poured over NIM:Files but can't find anything else remotely applicable.

Thanks,
Harry
_______________________________________
Harry Hahn <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 4 Jun 1995 12:03:27 -0400
Organization: America Online, Inc. (1-800-827-6364)

Harry Hahn wrote:
>How does one copy a file from one volume to another? It looks like none
of
>the FS calls work across volumes and though PBHCopyFile looked like the
>ticket, I get a -50 error (paramError-function not supported by volume).

PBHCopyFile copies files between two locations on the *same* remote file
server. It lets the server perform the copy rather than moving the data to
your client and back.

What you want is a function named FileCopy (HFileCopy and FSpFileCopy) in
the Apple sample code "MoreFiles." FileCopy uses PBHCopyFile if it can; if
it cannot, FileCopy performs the copy with its own code. You get the
source code to MoreFiles, so if you feel like adding a progress dialog or
anything like that, you can change the code.

- Jim Luther

+++++++++++++++++++++++++++

>From Toby <[e-mail]>
Date: 5 Jun 1995 15:16:44 GMT
Organization: MultiMedia Corporation

You could do it manually (may be faster) by opening the resource file and
data file on the source volume, creating the output files and then for
each open file do a while(!eof) read/write thing...?

Well, it seems like the easiest method to me!

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Mon, 05 Jun 1995 22:17:55 -0500
Organization: nil

In article <[e-mail]>,
[e-mail] (Harry Hahn) wrote:

> How does one copy a file from one volume to another? It looks like none of
> the FS calls work across volumes and though PBHCopyFile looked like the
> ticket, I get a -50 error (paramError-function not supported by volume).
>
> I've poured over NIM:Files but can't find anything else remotely applicable.
>

There's no function in Mac OS for a file copy from one volume to another.
Instead, you have to handle that yourself--a pain unless you do one of two
things:

Either "ask" the Finder to copy it for you (via AppleScript), or use the
MoreFiles library from Apple DEvelopper Technical Support (DTS).  This DTS
library is available on a number of FTP sites (including apple's
ftp.apple.com), and contains a welth of utilities for handling files,
including file copy commands.  Everything comes with sources.

Martin-Gilles Lavoie

Martin-Gilles Lavoie
- ------------------------------------------------------------------------------
   The company I work for has it's own opinions.  So do I.  -- MGL
- ------------------------------------------------------------------------------

---------------------------

>From [e-mail] (Greg Finnegan)
Subject: Creating alias files
Date: Mon, 5 Jun 1995 23:44:38 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Does anybody have any code snippets (or pointers to code snippets)
for creating an alias file programatically (e.g. given an FSSpec
to a file and an FSSpec to a folder, create an alias file in the
specified folder). I realiaze that the alias file format is
proprietary, but I'm willing to live with code than may break
in the future because I REALLY need this now (it is beyond me
why the format of the 'alis' resource in an alias file is different
than the handle created by NewAlias()).

Someone mentioned an article in MacTutor a while back. I would
apreciate any info on that too.

Greg.
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Josh Adams)
Date: Mon, 05 Jun 1995 23:31:28 -0400
Organization: University of Maryland College Park

In article <[e-mail]>, [e-mail] (Greg Finnegan) wrote:

> Does anybody have any code snippets (or pointers to code snippets)
> for creating an alias file programatically (e.g. given an FSSpec

I have some code that is supposed to send a Make Alias apple event to the
finder. However, at this moment it doesn't work. Also, I want to then
move that alias to another folder, but I don't know the best way to do this.
(How to select it? Not all aliases will end in " alias", since SpeedyFinder
can change what you stick on and in other countries, who knows. Can't go by
latest created file, because that might not be accurate if something makes
a file (well, i suppose if you don't call WaitNextEvent, another file CAN'T
be created... hmmm. Maybe that's how I'll do it)

Anyway, if you ever find a way to move that alias (like Alias Director does)
and if you get good code to make the alias, could you forward it to me? I'll
do the same if I find anything. If you want what I have, tell me...

Josh

--
Josh Adams                       |  Will she trick or treat,
Mail: [e-mail]         |  I bet she will.
Talk: [e-mail]      |    - Type O Negative

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 6 Jun 1995 16:37:39 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Josh Adams <[e-mail]> wrote:

>> Does anybody have any code snippets (or pointers to code snippets)
>> for creating an alias file programatically (e.g. given an FSSpec

As far as I know, there is no official way of creating aliases (Apple
says aliases are strictly a user thing, which is stupid).

So you just roll your own: create a resource file, create an alias handle
with NewAlias, write it as an 'alis' 0 resource, set the file's isAlias
bit. That should do the trick.

Hope this helps,



--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Telesis North)
Date: Tue, 6 Jun 1995 17:37:29 GMT
Organization: undecided

In article <[e-mail]>, [e-mail] (Greg Finnegan) wrote:
> Does anybody have any code snippets (or pointers to code snippets)
> for creating an alias file programatically (e.g. given an FSSpec

See Technote TB-535:Finder Q&A's.

- -
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
"Bigboo-TAY! Boo-TAY!!"

+++++++++++++++++++++++++++

>From [e-mail] (David Walton)
Date: Tue, 06 Jun 1995 13:08:38 -0500
Organization: University of Notre Dame, OUC

In article <[e-mail]>, [e-mail] (Greg Finnegan) wrote:

>Does anybody have any code snippets (or pointers to code snippets)
>for creating an alias file programatically (e.g. given an FSSpec
>to a file and an FSSpec to a folder, create an alias file in the
>specified folder). I realiaze that the alias file format is
>proprietary, but I'm willing to live with code than may break
>in the future because I REALLY need this now (it is beyond me
>why the format of the 'alis' resource in an alias file is different
>than the handle created by NewAlias()).
>

Alias files created with NewAlias work fine from the Finder.  Here's a
routine I used a long time ago:


void MakeAliasFile(FSSpecPtr aliasFile, FSSpecPtr target, ResType fType,
ResType fCreator)
{
   AliasHandle    alias;
   short          refNum;
   FInfo          fileInfo;
   OSErr          error;

   FSpCreateResFile(aliasFile, fCreator, fType, smSystemScript);
   error = ResError();
   refNum = FSpOpenResFile(aliasFile, fsRdWrPerm);
   error = NewAlias(nil, target, &alias);
   AddResource((Handle)alias, 'alis', 0, target->name);
   CloseResFile(refNum);
   error = FSpGetFInfo(aliasFile, &fileInfo);
   fileInfo.fdFlags |= fIsAlias;
   error = FSpSetFInfo(aliasFile, &fileInfo);
}

--
David Walton                    |  Macintosh Consultant & Graduate Student
Mailto:[e-mail]   |  Office of University Computing
http://www.nd.edu/~dwalton1/    |  Dept. History & Philosophy of Science
Voice: 219-631-8024             |  University of Notre Dame

    "Beware the advice of successful people; they do not seek company."

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Wed, 07 Jun 1995 02:18:14 -0700
Organization: Skunkworks

In article <3r208j$[e-mail]>, [e-mail] (Francois
Pottier) wrote:
>As far as I know, there is no official way of creating aliases (Apple
>says aliases are strictly a user thing, which is stupid).

Specifically, tech note FL 30 says:

  Finder alias files are one aspect of the Macintosh human
  interface considered "reserved for users."  The internal
  format of Finder alias files is intentionally undefined
  because it is subject to change and because Finder alias
  files should be neither created nor altered by
  applications. The Finder is the user's domain, and Finder
  alias files are a user convenience.

The note makes little pretense of keeping the contents of alias files a
secret: they are alias resources, created by the Finder, stored in a
file.  There is even a supported way to create them: send an Apple event
to the scriptable Finder.

I'm sure every application developer thinks that users would love to have
an alias to their app on the desktop or in the startup items folder.  But
the general principle stands: the Finder environment should be under the
control of the user.

Grobbins                                  [e-mail]


---------------------------

>From [e-mail] (K. Beeghly)
Subject: Design flaw of the Drag Manager?
Date: 24 May 1995 20:45:55 GMT
Organization: University of Washington


I've been working on this for a few days now, and could really use some
insight....

I'm adding Drag & Drop functionality to my app.  The problem:  my app
uses the ENTIRE contents of it's window (none of it is white), it's a color
window, and I have encountered two bugs (I think):

1. If I edit the WIND resource and change the window from 'Default' to
'Custom', and run my app, when I drag a file into the window I get a
'light gray' border instead of the expected 'light blue' border.  This
happens even if the background color is WHITE and happens weither I draw
the contents of my window or not. For example, when I changed my code to..

void DoUpdate( WindowPtr wp )
{
        GrafPtr                 oldPort;
        GetPort( &oldPort );
        SetPort( wp );
        BeginUpdate( wp );
        EraseRgn( wp->visRgn );

        if( !EmptyRgn( wp->visRgn ) )
        {
                //DrawContents( wp );
        }
        EndUpdate( wp );
        SetPort( oldPort );
}
...it still draws the border in gray, so I believe I'm
not doing anything to cause this.

What's the problem?  Why not just live with the gray border?  Well, the
contents of the window is painted gray, so when a user drags a file into
my app, they can't tell that the app accepts dropped files!

The solution:  Just use the 'Default' option.  I'll have to paint the
window gray myself, but at least I'll still get the blue border.  Well, I've
encountered some other problems...

A portion of the border of my window is black, and when I drag af file
into the window, there is no change on the black portion of the border,
and there is NO INDICATION that the window accepts any files!

For example, if I have the WIND resource useing the 'Default' option, and
I use the following to draw/update my window:


void DoUpdate( WindowPtr wp )
{
        GrafPtr                 oldPort;
        GetPort( &oldPort );
        SetPort( wp );
        BeginUpdate( wp );
        EraseRgn( wp->visRgn );

        if( !EmptyRgn( wp->visRgn ) )
        {
                //DrawContents( wp );
                FillRect(&wp->portRect, &qd.black);
        }
        EndUpdate( wp );
        SetPort( oldPort );
}

I get a window filled with black (expected).  If I drag a file into the
window, neither a blue border nor the gray border is drawn!  The user has
no way of knowing that the window accepts dropped files!

I guess I could create a custom cursor, and change the cursor if it
enters the contents of my window, but I really want to adhere to the HIG
that Apple has set up for the drag manager.  As far as I can tell, I'm
doing everything right!

Has anybody else encountered this?  Is there a tech note on it?



PS.  Yes, I am using a GetNewCWindow call to create the window.
PPS.  I tested out "ReceiveDragDemo' by Gregory H. Dow (from Dave Marks'
'Ultimate Mac Progrmming' book), and it does the same thing.
PPPS.  Right now, I'm using flavorTypeHFS for my flavor, but I only want
to accept FILES, not FILES and FOLDERS.  Is there a flavor for this?


Thanks,


Jeff


+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 25 May 1995 15:47:46 GMT
Organization: National Renewable Energy Laboratory

In article <3q05u3$[e-mail]> K. Beeghly,
[e-mail] writes:
>I get a window filled with black (expected).  If I drag a file into the
>window, neither a blue border nor the gray border is drawn!  The user has
>no way of knowing that the window accepts dropped files!

I ran into the same problem--its a consequence of the way the Drag
Manager draws the highlighting (using the QuickDraw Hilite mode, if I
remember correctly).  My solution was to inset the rectangle where the
window's content is drawn by 2 pixels, leaving a white border where
drag highlights are drawn (inside the scroll bars also).  The border
turned out to be asthetically pleasing, and the drag highlights are now
easy to deal with.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Fri, 26 May 1995 11:31:34 +1200
Organization: University of Waikato

In article <3q05u3$[e-mail]>, [e-mail]
(K. Beeghly) wrote:

>I'm adding Drag & Drop functionality to my app.  The problem:  my app
>uses the ENTIRE contents of it's window (none of it is white), it's a color
>window, and I have encountered two bugs (I think):
>
>1. If I edit the WIND resource and change the window from 'Default' to
>'Custom', and run my app, when I drag a file into the window I get a
>'light gray' border instead of the expected 'light blue' border.  This
>happens even if the background color is WHITE and happens weither I draw
>the contents of my window or not.

I believe the Drag Manager uses QuickDraw's highlight mode to draw its
highlight. This would mean the highlight colour only appears where the
background colour is currently being displayed. Have you tried setting the
background colour in your window's CGrafPort to match the background that
you're drawing?

Another possibility is to use your own highlight code. You could install
your own highlight action in the drag, or, what I suspect would be
simpler, draw your highlight directly and don't bother calling
Show/HideDragHilite at all. (After all, you're the one responsible for how
the drag appears in your own windows.)

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Sun, 28 May 1995 11:51:16 +0200
Organization: Myself

In article <3q05u3$[e-mail]>, [e-mail]
(K. Beeghly) wrote:

> 1. If I edit the WIND resource and change the window from 'Default' to
> 'Custom', and run my app, when I drag a file into the window I get a
> 'light gray' border instead of the expected 'light blue' border.  This
> happens even if the background color is WHITE and happens weither I draw
> the contents of my window or not. For example, when I changed my code to..

[snip]

> ...it still draws the border in gray, so I believe I'm
> not doing anything to cause this.
>
> What's the problem?  Why not just live with the gray border?  Well, the
> contents of the window is painted gray, so when a user drags a file into
> my app, they can't tell that the app accepts dropped files!

The problem resides in the wctb resource.
If you want a color window with the standard colors, just use an 8-byte
size wctb resource (you can find it in any Drag Manager-savvy application
with ResEdit).

> Has anybody else encountered this?  Is there a tech note on it?

Oh, yes, there IS a technote somewhere in the Apple Internet servers.
Basically, the wctb/dctb etc. resource format HAS CHANGED!
That is, the one documented in IM V is no more current.

--
--
 Fabrizio Oddone <[e-mail]>
http://www.di.unito.it/pub/WWW/www_student/apple/FabrizioOddone/

+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: Sun, 28 May 1995 10:50:08 -0400
Organization: Harvard University

In article <[e-mail]>, [e-mail]
(Fabrizio Oddone) wrote:

> Oh, yes, there IS a technote somewhere in the Apple Internet servers.
> Basically, the wctb/dctb etc. resource format HAS CHANGED!
> That is, the one documented in IM V is no more current.

The wctb/dctb color table resources changed four years ago with the release
of System 7.  Unfortunately, ResEdit isn't clever enough to know that or
react accordingly.  The tech note in question describes the additional
fields for various tinge and highlight colors, and it was recently modified
to show how to update those tinge colors when the user modifies them in the
"Color" control panel.

-- Greg Landweber
   [e-mail]
(author of "Greg's Buttons" and "Greg's Browser")

+++++++++++++++++++++++++++

>From Simon Fraser <[e-mail]>
Date: 3 Jun 1995 13:11:55 GMT
Organization: NERC Centre for Population Biology, Imperial College

[e-mail] (Lawrence D9Oliveiro) wrote:
>In article <3q05u3$[e-mail]>, [e-mail]
>(K. Beeghly) wrote:
>
>>I'm adding Drag & Drop functionality to my app.  The problem:  my app
>>uses the ENTIRE contents of it's window (none of it is white), it's a color
>>window, and I have encountered two bugs (I think):
>>
>>1. If I edit the WIND resource and change the window from 'Default' to
>>'Custom', and run my app, when I drag a file into the window I get a
>>'light gray' border instead of the expected 'light blue' border.  This
>>happens even if the background color is WHITE and happens weither I draw
>>the contents of my window or not.
>
>I believe the Drag Manager uses QuickDraw's highlight mode to draw its
>highlight. This would mean the highlight colour only appears where the
>background colour is currently being displayed. Have you tried setting the
>background colour in your window's CGrafPort to match the background that
>you're drawing?
>
>Another possibility is to use your own highlight code. You could install
>your own highlight action in the drag, or, what I suspect would be
>simpler, draw your highlight directly and don't bother calling
>Show/HideDragHilite at all. (After all, you're the one responsible for how
>the drag appears in your own windows.)

You should take a look at:

http://www.http://www.info.apple.com/dev/technotes/Toolbox/tb_33.html

which discussed the new wctb resource format and its effects on
Drag hilite colours.

_________________________________________________________________
Simon Fraser                   NERC Centre for Population Biology
[e-mail]                Imperial College at Silwood Park
                                       Ascot, Berks.  SL5 7PY  UK


---------------------------

>From [e-mail] (Thomas Haggie)
Subject: How to do a time-to-finnish bar...
Date: 1 Jun 1995 17:02:43 +0100
Organization: Electronics and Computer Science, University of Southampton

Hello,
        I have been looking to see how to create a dialogue that will display
the completion status of some of my routines, to give an idea of how much
longer they're going to take, like in the dialog produced when copying large
files. Basically to fit somehow to a loop processing stuff of a known length
a for loop for example. I'd have thought there'd be some sort of standard OS
routing like SFGetFile for files, as it's such a commonly needed thing. If
anyone could point me in the direction of some sample code/resources I'd be
much obliged, I'd have thought that this would also be a useful addition to the
Mac Programming FAQ...

_____________________.                  -*TOM*-
[e-mail]|


+++++++++++++++++++++++++++

>From [e-mail] (Kevin Courter)
Date: Fri, 02 Jun 1995 07:33:10 -0600
Organization: U.S. West Technologies

In article <3qkob3$[e-mail]>, [e-mail]
(Thomas Haggie) wrote:

> Hello,
>         I have been looking to see how to create a dialogue that will display
> the completion status of some of my routines, to give an idea of how much
[snip]

Hi Tom.

I don't know about a bar that tells when you are turning into a
resident of Finland (ok, I couldn't resist) but a package that
compiles under MPW, Think, and CodeWarrior is called CModalProgress
and I got it from the CW site - here's the URL:

http://www.iquest.com/~fairgate/cw/pp-index.html

or

via anonymous ftp to ftp.iquest.com in
/pub/fairgate/pplant/CModalProgress.hqx.


I think I had to tweak it a bit to build under MPW - CW is it's native
environment.  I wrapped it up in a class to allow me to set it up and
start it running in a very simple manner - here's the type of
interface I created as a wrapper:

#ifndef __CProgress__
#define __CProgress__

class CModalProgress;

// The types of progress indicators available
// Note: Progress Bar and Progress Text are both
// of type kPercentageProgress
static const short   kInfiniteProgress = 1;
static const short   kPercentageProgress = 2;

// timeout == 60ths of a second until the progress box appears
static const kStandardProgressTimeout = 60 * 2;    // 2 seconds


class CProgress
{
public:
   CProgress(  const char* operationName,
               short type,
               short infDialogResID = 0,
               short progDialogResID = 0);

   virtual           ~CProgress();

   virtual Boolean   StartProgress( long timeout);
   virtual void      EndProgress( void );

      // Call SetProgressPercent periodically if you created
      // a kPercentProgress bar (i.e., it shows percent complete).
   virtual Boolean SetProgressPercent( short percent,
                                       const char* minorMessage=NULL,
                                       const char* majorMessage = NULL );

      // Call TickProgress periodically if you created a
      // kInfiniteProgress
bar
   virtual Boolean TickProgress( const char* minorMessage=NULL,
                                 const char* majorMessage = NULL );

protected:
   virtual Boolean MakeProgress(  );

private:

   CModalProgress* fProgressDialog;

   long                 fProgressTimeoutTime;
   Boolean              fProgressRunning;
   Str255               fProgressOperationName;
   Str255               fMajorMessage;
   Str255               fMinorMessage;

   short                fType;
   short                fInfiniteDialogResID;
   short                fPercentageDialogResID;
};


It hides the creation of the dialog, and a few other details
that aren't too bad anyway ( CModalProgress is a very nice
package) but that I wanted to see even less of.  To make it
easier to attach/detach progress views from a lengthy process (i.e.,
if it's running without GUI or without interaction) I just put
a hook routine in the lengthy process's class, something like
void DoProgress( float percentComplete )
{
   if ( fProgressFunction )
   {
      (*fProgressFunction)( percentComplete, "A message", "AnotherMessage" );
   }
}

That way the caller of the process class can determine whether
there is a progress bar available and install it as a callback
function in the process class (or not).

Good luck, hope this helps some.  Email me if you have questions.

Kevin

--
Kevin Courter
US WEST Advanced Technologies    -    Boulder, Colorado

---------------------------

>From [e-mail] (Steve Herman)
Subject: How to get TCP-IP address?
Date: Thu, 01 Jun 1995 11:34:10 -0500
Organization: CSC

I'm looking for a quick and easy way to get the local machine's TCP/IP
address from within a program.

Any pointers to documentation, or sample code would be appreciated.

Thanks,
Steve

- --------------------------------------------------
- Steve Herman - PrISMS
- Computer Sciences Corporation
- Marshall Space Flight Center
- Huntsville, AL
- --------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Thu, 01 Jun 1995 18:18:26 -0800
Organization: In Phase Consulting

In article <[e-mail]>,
[e-mail] (Steve Herman) wrote:

> I'm looking for a quick and easy way to get the local machine's TCP/IP
> address from within a program.
>
> Any pointers to documentation, or sample code would be appreciated.

Using MacTCP, you can get the IP address of the local system through
calling the MacTCP driver's GetMyIPAddr control call.

This is documented on page 82 (Miscellaneous Interfaces) of the
MacTCP programming manual.

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (David Walton)
Date: Fri, 2 Jun 1995 03:35:10 GMT
Organization: University of Chicago, Academic and Public Computing

In article <[e-mail]>,
Steve Herman <[e-mail]> wrote:

>I'm looking for a quick and easy way to get the local machine's TCP/IP
>address from within a program.


Sorry; I forgot to add in my earlier post that you'll need to open the
MacTCP driver, e.g., with

   error = OpenDriver("\p.IPP", &refNum);

and pass in refNum to the ioVRefNum field of the parameter block.

You are, BTW, talking about the machine's IP (user-configured)
address, not the Ethernet (hardware) address?

--
David Walton                    |  Macintosh Consultant & Graduate Student
Mailto:[e-mail]   |  Office of University Computing
http://www.nd.edu/~dwalton1/    |  Dept. History & Philosophy of Science
Voice: 219-631-8024             |  University of Notre Dame

+++++++++++++++++++++++++++

>From [e-mail] (John Norstad)
Date: Thu, 01 Jun 1995 23:51:22 -0500
Organization: Northwestern University

In article <[e-mail]>,
[e-mail] (Steve Herman) wrote:

> I'm looking for a quick and easy way to get the local machine's TCP/IP
> address from within a program.
>
> Any pointers to documentation, or sample code would be appreciated.

Here's the function I use in NewsWatcher. It's got both Open Transport
code and MacTCP code. Note this function isn't reusable by itself. For
details, see the "net.c." module in the full NewsWatcher source code,
available at <URL:ftp://ftp.acns.nwu.edu/pub/newswatcher/>.

Notice how much easier Open Transport is to program to do this than is
MacTCP. This is usually the case.

/*----------------------------------------------------------------------------
   NetGetMyAddr

   Get this Mac's IP address.

   Exit: function result = error code.
         *addr = the IP address of this Mac.

   With Open Transport, if the Mac has more than one IP interface, the
   IP address of the default interface is returned.
- --------------------------------------------------------------------------*/

OSErr NetGetMyAddr (unsigned long *addr)
{
   struct GetAddrParamBlock pBlock;
   OSErr err = noErr, giveTimeErr = noErr;
   static Boolean gotIt = false;
   static unsigned long myAddr;
   InetInterfaceInfo ifaceInfo;

   if (!gotIt) {

      if (gHaveOT) {

         err = OTInetGetInterfaceInfo(&ifaceInfo, kDefaultInetInterface);
         if (err != noErr) return TranslateErrorCode(err);
         myAddr = ifaceInfo.fAddress;

      } else {

         memset(&pBlock, 0, sizeof(pBlock));
         pBlock.ioResult = 1;
         pBlock.csCode = ipctlGetAddr;
         pBlock.ioCRefNum = gRefNum;
         PBControlAsync((ParmBlkPtr)&pBlock);
         while (pBlock.ioResult > 0) {
            giveTimeErr = (*gGiveTime)();
            if (err == noErr) err = giveTimeErr;
         }
         if (err != noErr) return TranslateErrorCode(err);
         err = pBlock.ioResult;
         if (err != noErr) return TranslateErrorCode(err);
         myAddr = pBlock.ourAddress;

      }

      gotIt = true;
   }

   *addr = myAddr;
   return noErr;
}

--
John Norstad
Academic Computing and Network Services
Northwestern University
[e-mail]
http://charlotte.acns.nwu.edu/jln/jln.html

+++++++++++++++++++++++++++

>From [e-mail] (David Walton)
Date: Thu, 01 Jun 1995 14:17:18 -0500
Organization: University of Notre Dame, OUC

In article <[e-mail]>,
[e-mail] (Steve Herman) wrote:

> I'm looking for a quick and easy way to get the local machine's TCP/IP
> address from within a program.


#include <MacTCP.h>

OSErr GetMyIPAddress(ip_addr *myAddr, long *myNetMask, short drvrRefNum)
{
   GetAddrParamBlock    PB;
   OSErr                error;

   /* Be sure to zero out appropriate fields, too */
   PB.ioVRefNum = drvrRefNum;
   PB.ioCRefNum = drvrRefNum;
   PB.csCode = ipctlGetAddr;
   error = PBControl((ParmBlkPtr)&PB, false);
   if (!error)
   {
      *myAddr = PB.ourAddress;
      *myNetMask = PB.ourNetMask;
   }
   return(error);
}

--
David Walton                    |  Macintosh Consultant & Graduate Student
Mailto:[e-mail]   |  Office of University Computing
http://www.nd.edu/~dwalton1/    |  Dept. History & Philosophy of Science
Voice: 219-631-8024             |  University of Notre Dame

    "Beware the advice of successful people; they do not seek company."

+++++++++++++++++++++++++++

>From Toby <[e-mail]>
Date: 6 Jun 1995 00:51:48 GMT
Organization: MultiMedia Corporation

Also note that whenver you make a TCP call your TCPiopb will have your IP
address in it.  That is, if you open MacTCP and then you want your IP
address you must make the PBControl call (as demonstrated in this thread)
but if you have made some other TCP calls (like opening a stream) then
the TCPiopb that you used for that stream will have your IP address
stored in it.

Just a thought...someone might be interested.

[e-mail]

---------------------------

>From [e-mail] (Graham)
Subject: PICS file format?
Date: 31 May 1995 09:39:05 +0100
Organization: Demon Internet News Service

Does anyone know how PICS files are laid out and how to parse them? I
think they are just a series of PICT s, but beyond that I don't know.

any help appreciated, many thanks in advance, Graham.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Thu, 01 Jun 1995 14:43:14 +1200
Organization: University of Waikato

In article <3qh9v9$[e-mail]>, [e-mail] (Graham)
wrote:

>Does anyone know how PICS files are laid out and how to parse them? I
>think they are just a series of PICT s, but beyond that I don't know.

Yup, that is the essence of a PICS file--a sequence of PICT resources,
numbered from 128. The bounds of the first one defines the bounds of the
animation; as I recall, it is permissible for the remaining ones to to
cover just parts of the area of the first one, which would speed up
animations if you just draw them one on top of the other.

There is also an option for an INFO resource, which contains things like
the depth of the images, the signature of the application that created the
file, and other less-than-vitally-important stuff.

Here are the data structure definitions that I used for my Movie
Conversion utility
<ftp://sumex-aim.stanford.edu/grf/util/movie-conversion-hc.hqx>:

DEFINITION MODULE PICSFormat;
(*
    Definitions for the PICS basic animation format.

    Written by LDO 1992 January 3.
    Last modified 1992 January 4.
*)

    FROM Types IMPORT
        OSType;

    CONST
        PICSFileType = 050494353H (* 'PICS' *);

    CONST
        PictureResType = 050494354H (* 'PICT' *);
        FirstPictureResID = 128; (* picture frames are numbered
sequentially from this *)
        InfoResType = 0494E464FH (* 'INFO' *);
        InfoResID = 128; (* ID of optional INFO resource *)

    CONST
        PICSInfoVersion = 0; (* current version of INFO structure *)
    TYPE
        PICSInfoRecord = (* layout of INFO resource *)
            RECORD
                BWColor : INTEGER; (* 0 for B/W, 1 for color/grayscale *)
                PixelDepth : INTEGER;
                Speed : INTEGER; (* positive frames/second or negative
seconds/frame *)
                Version : INTEGER; (* = PICSInfoVersion *)
                Creator : OSType;
                LargestPictureSize : LONGCARD (* size in bytes of largest
picture, or 0 if unknown *)
            END (*RECORD*);
        PICSInfoPtr = POINTER TO PICSInfoRecord;
        PICSInfoHandle = POINTER TO PICSInfoPtr;

END PICSFormat.

---------------------------

>From [e-mail] (jda)
Subject: PPC and SIZE resource
Date: Tue, 30 May 1995 16:21:15 GMT
Organization: National Institutes of Health

Can anyone tell me how to set the memory partitions in the SIZE
resource for fat applications? There is nothing in the IM PPC book
about this. I want to have different partitions for the two operating
environments, obviously, but it's not obvious how to set them
separately.

I know what ids of -1 and 0 mean, but what does id 1 mean?

Thanks for any reply,

Jon

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Thu, 1 Jun 1995 13:38:50 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (jda) wrote:

> Can anyone tell me how to set the memory partitions in the SIZE
> resource for fat applications? There is nothing in the IM PPC book
> about this. I want to have different partitions for the two operating
> environments, obviously, but it's not obvious how to set them
> separately.

You can't set separate partition sizes for PPC and 68k. The system will,
however, automatically decrease your partition size by the size of your
code fragment when VM is turned on, since your fragment occupies no
virtual address space in that case.
If you really need to do this, build separate 68k and PPC apps. I tend not
to like fat apps since they take up extra disk space...

(The SIZE 1 resource is added by the Finder to store the user's customized
setting for the partition size if they modify it in the Get Info window.
It overrides SIZE -1. I'm not sure what SIZE 0 does.)


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

                LLAMA: NO FEAR OF SPIKES

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 02 Jun 1995 08:12:34 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

>
> (The SIZE 1 resource is added by the Finder to store the user's customized
> setting for the partition size if they modify it in the Get Info window.
> It overrides SIZE -1. I'm not sure what SIZE 0 does.)

  SIZE -1 is the developer's original
  SIZE 0 is what Finder has long created when the user changes the
"preferred" partition size.  Holds "suggested" and "preferred"
  SIZE 1 was added when the "minimum" size was added to the mix (Sys
7???--I forget), since there are only two size values in the resource
format.  Holds "suggested" and "minimum".

Yet one more kludge brought on by the non-black-box nature of old system
structures, along with all the extra barnacles hung on the window record
for color windows, and <your favorite example here>
    --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       I don't do windows.
   [e-mail]

---------------------------

>From [e-mail] (Jon Steinmetz)
Subject: Pausing SndPlayDoubleBuffer
Date: Fri, 19 May 1995 13:50:47 -0600
Organization: IVI Publishing, Inc.

  How does one pause the playing of SndPlayDoubleBuffer?  Both sending an
immediate pauseCmd and calling SndPauseFilePlay do not seem to work.  Do I
have to implement this myself?

--
// Jon Steinmetz
// IVI Publishing, Inc.
//    work:     [e-mail]
//    personal: [e-mail]
//    web page: http://www.umn.edu/nlhome/g262/stein045/

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 23 May 1995 14:17:10 GMT
Organization: Helsinki University of Technology

In article <jons-1905951350470001@199.199.200.217> [e-mail] (Jon Steinmetz) writes:
>  How does one pause the playing of SndPlayDoubleBuffer?  Both sending an
>immediate pauseCmd and calling SndPauseFilePlay do not seem to work.  Do I
>have to implement this myself?

Sounds like the obvious solution to me. Or you could close the channel and
open it again, if you expect a very long pause.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From SuperStudio <[e-mail]>
Date: 28 May 1995 14:00:08 GMT
Organization: via CompuServe Information Service

A while ago, Dev Support told me that you had to set the rate to 0.
It is kind of sad if that member of Dev Support did not think it is
worth publicizing the response since it is an admittedly unobvious
solution.  Anyhow, here is the code:
Pause sound :
err = HSndDoImmediate(getRateCmd, 0, (long)&SndPaused);
err = HSndDoImmediate(rateCmd, 0, 0);
Resume:
err = HSndDoImmediate(rateCmd, 0, SndPaused);

OSErr HSndDoImmediate(cmdType, param1, param2)
{
        cmd.cmd = cmdType;
        cmd.param1 = param1;
        cmd.param2 = param2;

        return SndDoImmediate(SndChan, &cmd);
}

---------------------------

>From [e-mail] (Steve Bryan)
Subject: QD3d in develop 22
Date: Thu, 25 May 1995 16:29:25 GMT
Organization: Sexton Software

All you developers who are interested in hands on access to QuickDraw 3d
just watch your mailbox for develop issue 22 to arrive (of course you
subscribe). Besides being the feature article (by Pablo Fernicola and Nick
Thompson) it looks like all the needed software (libraries, header files)
is included. There is even a disk version of the QD3d volume of Inside
Mac.

--
|Steve Bryan                Internet: [e-mail]
|Sexton Software          CompuServe: 76545,527
|Minneapolis, MN 55415           Fax: [phone]
|PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D  E1 8C A6 9B A9 BE 96 CB

+++++++++++++++++++++++++++

>From [e-mail] (Dan Peterson)
Date: Tue, 30 May 1995 06:27:33 -0700
Organization: Apple Developer Press

In article <[e-mail]>,
[e-mail] (Steve Bryan) wrote:

> All you developers who are interested in hands on access to QuickDraw 3d
> just watch your mailbox for develop issue 22 to arrive (of course you
> subscribe). Besides being the feature article (by Pablo Fernicola and Nick
> Thompson) it looks like all the needed software (libraries, header files)
> is included. There is even a disk version of the QD3d volume of Inside
> Mac.

...and the QD3D database for Toolbox Assistant will be available within
the next week or so. Keep your browser tuned to:
http://www.info.apple.com/dev/MPTA.html

Dan Peterson,
Developer Press,
Apple Computer, Inc.

---------------------------
>From [e-mail] (Dan Peterson)
Subject: QuickDraw 3D Database for Toolbox Assistant now available!
Date: Wed, 07 Jun 1995 10:26:40 -0700
Organization: Apple Developer Press

Hey,

Just a quick note to let you know that the QuickDraw 3D database for
Macintosh Programmer's Toolbox Assistant is now available via our Web site
at:
http://www.info.apple.com/dev/MPTA.html

if you want direct access to the software on our FTP site:

host: ftp.info.apple.com
path:
Apple.Support.Area/Developer_Services/Technical_Documentation/Toolbox_Assistant_Updates/

This new QuickDraw 3D database requires the latest version of the
"Routines A...Z and Mgr.qv" file, also available at the aforementioned
locations.

This is part of our continuing effort to provide up-to-date reference
information in a timely manner.

As always, please send comments and suggestions regarding Macintosh
Programmer's Toolbox Assistant to [e-mail].


Thanks,
Dan Peterson,
Developer Press,
Apple Computer, Inc.

---------------------------

>From [e-mail] (Joel Quejada)
Subject: Techniques for collision detection
Date: 17 May 1995 13:36:57 GMT
Organization: Texas Instruments, Inc.


What are the different techniques used for detecting collisions between
sprites? I use with a great deal of success the "union rect" technique,
where you compare two sprites' rects, if they overlap then you assume a
collision just happened.

However, the technique above only works great for rectangular (or
mostly rectangular) sprites. How about for more irregular sprites?
What types of collision detection techniques are used for these?

Joel

--

+++++++++++++++++++++++++++

>From David Hay <djh>
Date: 17 May 1995 14:38:56 GMT
Organization: Los Alamos National Laboratory

[e-mail] (Joel Quejada) wrote:
>
>What are the different techniques used for detecting collisions between
>sprites? I use with a great deal of success the "union rect" technique,
>where you compare two sprites' rects, if they overlap then you assume a
>collision just happened.
>
>However, the technique above only works great for rectangular (or
>mostly rectangular) sprites. How about for more irregular sprites?
>What types of collision detection techniques are used for these?
>

        I think that the method you use depends a great deal on the sprites
        that are colliding. For example, if you have to roughly square
        sprites, then just checking for rectangle over lap is enough. But if
        you have a couple balls bouncing off each other, it might make sense
        to see if the balls are within a certain distance of each other.

        One method that I just thought of would be to make a region out of
        each sprite's mask. Then intersect the two regions and if the resulting
        region is not empty, then the two have collided. I haven't tried this
        and it may be too slow to use in a game, but might be worth a try.

        What SpriteWorld does is just test if the rectangles overlap and call
        a user defined routine if they do, allowing more refined collision
        detection to occur once the possibility of a collision has been
        established. It could be that a combination of this technique and
        the region intersection I suggested might work pretty well. (My
        fingers are starting to get itchy to try this out :-)

        Hope that helps!
--
- -----------------------------------------------------------------------+
David Hay                         "Failure has a thousand explanations.  |
[e-mail]                Success doesn't need one."            |
University of Colorado, Boulder          -Sir Alec Guinness  _-^-_       |
Finger for PGP Public Key                                   / o o \      |
http://ugrad-www.cs.colorado.edu/~hay/Home.html -------OOO-'---U---`-OOO-+


+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 17 May 1995 14:58:57 GMT
Organization: LMC-IMAG Grenoble France

In article <3pcu5p$[e-mail]>, [e-mail] (Joel
Quejada) wrote:

>What are the different techniques used for detecting collisions between
>sprites? I use with a great deal of success the "union rect" technique,
>where you compare two sprites' rects, if they overlap then you assume a
>collision just happened.
>
>However, the technique above only works great for rectangular (or
>mostly rectangular) sprites. How about for more irregular sprites?
>What types of collision detection techniques are used for these?
>


Hi Joel,

i don't know the techniques used for that,
but my idea about this subject is to use Region,
because there is a proc. SectRgn who calculate
the intersection of two rgns (see description below).

PROCEDURE SectRgn (srcRgnA,srcRgnB,dstRgn: RgnHandle);

    SectRgn calculates the intersection of two regions and places the
intersection in a third region. THIS DOES NOT CREATE THE DESTINATION
REGION:  you must use NewRgn to create the dstRgn before you call
SectRgn. The dstRgn can be one of the source regions, if desired.

    If the regions do not intersect, or one of the regions is empty, the
destination is set to the empty region (X,X,X,X).

With this proc., the method for detecting sprites collisions seems easy:

- set RgnA (describe the rgn of sprite A)
- set RgnB (describe the rgn of sprite B)
- init. CollisionRgn
- SectRgn(RgnA,RgnB,CollisionRgn)
- if CollisionRgn is the empty rgn
      then there is no collision between A and B
      else there is a collision
- ...

Hope this helps.
Fr
_____________________________________________________
F.R. Degott  ([e-mail])
LogiMath at Lab. LMC-IMAG - Univ. Joseph Fourier - Grenoble - France

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Thu, 18 May 1995 11:49:56 GMT
Organization: University of Bristol, England

: In article <3pcu5p$[e-mail]>, [e-mail] (Joel
: Quejada) wrote:

: >What are the different techniques used for detecting collisions between
: >sprites? I use with a great deal of success the "union rect" technique,
: >where you compare two sprites' rects, if they overlap then you assume a
: >collision just happened.
: >
: >However, the technique above only works great for rectangular (or
: >mostly rectangular) sprites. How about for more irregular sprites?
: >What types of collision detection techniques are used for these?

        For most sprite games there is a general standard of doing a quick
check and then doing some more specific checking.

        If you have the rectangles of the sprites then you can start with
a simple SectRect call: for some games this is in fact all you need
(Maniac springs to mind :).

        However, you may wish to use something more accurate after you've
determined that the rectangles are touching, and the best approach is to
actually check the overlapping of the sprites 'pixel-by-pixel'. One method
is to draw one sprite in one position, and as you're drawing the second
sprite over top check, for each pixel, whether the destination is the
'black' entry in your colour palette (it's almost always 0 or 255, I
can't remember which!). Of course, you can think of interesting ways of
optimising this approach, but this is the general idea.

        Hope this helps! If you have any other questions, I'd be happy to
try and help more.




        Alex

--
Alex Metcalf             Windows 95: Just another
[e-mail]        pane in the glass.

http://www.fen.bris.ac.uk/students/am4001/welcome.html


+++++++++++++++++++++++++++

>From Josh Brown <[e-mail]>
Date: Thu, 18 May 1995 04:25:52 -0600
Organization: University of Utah Computer Science Department



On 17 May 1995, Joel Quejada wrote:

> What are the different techniques used for detecting collisions between
> sprites? I use with a great deal of success the "union rect" technique,
> where you compare two sprites' rects, if they overlap then you assume a
> collision just happened.
>
> However, the technique above only works great for rectangular (or
> mostly rectangular) sprites. How about for more irregular sprites?
> What types of collision detection techniques are used for these?

Joel,

  One way to do it is to find the SectRect of the two sprites, and then
use a bit routine (similar to a blitter) to see if any non-clear
(backgroud color) pixels in each sprite pixmap or bitmap overlap. This is
not unreasonably slow, since generally the overlapping area will be very
small. It should give you pixel-accurate collision checking.

  My experience is that the faster your sprites are moving, the less
precision in collision detection you need.

-josh brown

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Fri, 19 May 1995 07:42:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

If your shapes are both somewhat round, you can check the distance between
the center of the two shapes. The pure way would be:

if ( sqrt( dx * dx + dy * dy ) < ( r1 + r2 ) )
   {
      // potential collision
   }

// dx = x distance between centers
// dy = y distance between centers
// r1 = radius of shape 1
// r2 = radius of shape 2

However, square roots are slow, so instead check against the square of
each side:

if ( ( dx * dx + dy + dy ) < ( r1 + r2 ) * ( r1 + r2 ) )
   {
      // potential collision
   }

While this method is not generally useful, it can be very useful for some
cases and it is suprisingly fast.

Mick

+++++++++++++++++++++++++++

>From [e-mail] (Christer Ericson)
Date: Fri, 19 May 1995 13:46:38 GMT
Organization: Dept. of Computing Science, Umea Univ., 901 87 Umea, Sweden

In <[e-mail]> [e-mail] (Alex Metcalf) writes:
>: In article <3pcu5p$[e-mail]>, [e-mail] (Joel
>: Quejada) wrote:
>
>: >What are the different techniques used for detecting collisions between
>: >sprites? [...]
>
>       For most sprite games there is a general standard of doing a quick
>check and then doing some more specific checking.
>[...]
>       However, you may wish to use something more accurate after you've
>determined that the rectangles are touching, and the best approach is to
>actually check the overlapping of the sprites 'pixel-by-pixel'. One method
>is to draw one sprite in one position, and as you're drawing the second
>sprite over top check, for each pixel, whether the destination is the
>'black' entry in your colour palette (it's almost always 0 or 255, I
>can't remember which!). Of course, you can think of interesting ways of
>optimising this approach, but this is the general idea.

What Alex describes is the basic approach to pixel exact collision
detection which, while being "perfect", is slow as molasses. Much better
is the pixel-span approach to pixel exact collision detection: for each
scanline of the sprite you have two additional values, the offsets (relative
the left side of the bounding box) to the first and last non-transparent
pixel of that scanline. Checking whether two sprites collide now involves
an initial bounding box check, and if the bounding boxes overlap you
check if these spans overlap for the relevant scanlines. (If needed
keep a similar structure for each column of the sprite as well.)

These are several other approaches, for both approximate and exact
collision detection, but the pixel-span method gives a very nice
result, is fast, and is easy to code. I only wish Swoop used it
instead of a badly designed bounding box only approach. :-(


Christer Ericson. <this space for hire> http://www.cs.umu.se/~christer/
phone: [phone], fax: [phone], email: [e-mail]
Department of Computing Science, Umea University, S-901 87 UMEA, SWEDEN

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 18 May 1995 09:01:46 -0500
Organization: Powertools, Austin, Texas

In article <3pcu5p$[e-mail]>,

Joel Quejada <[e-mail]> wrote:
>
>What are the different techniques used for detecting collisions between
>sprites? I use with a great deal of success the "union rect" technique,
>where you compare two sprites' rects, if they overlap then you assume a
>collision just happened.
>
>However, the technique above only works great for rectangular (or
>mostly rectangular) sprites. How about for more irregular sprites?
>What types of collision detection techniques are used for these?

In developing the Graphic Elements system, I tested several different
collision-detection algorithms, and arrived at the following, which
gives a good compromise between speed and completeness:

First, intersect the rectangle of the object under consideration and
the rectangle of each object with which it might collide. This can
be done very rapidly, and eliminates most of the possibilities. (Hint:
an intersect-rect function is easy to write, and you probably want to
avoid the trap overhead of 68K Macs....)

Second, if the intersection is non-empty, compare the resulting rectangle
with that of the object under consideration. It is easy to determine
the octant in which the collision took place on the basis of this
comparison, and for many cases an eighth of a circle is close enough for
use as a "direction".

I also found it desirable to keep track of whether a collision was beginning,
continuing, or ending.

In Graphic Elements, the individual objects' collision functions are
called at this point (for both the collider and the "collidee"). The
above information is passed on to the collision function. When necessary,
this function can proceed to perform whatever additional tests are
deemed necessary by the application programmer -- for example, anding
the bitmaps of the relevant sections of the objects to see whether they
are "actually" touching.

                                        --Al Evans--
--
Al Evans                | Graphic Elements: A new standard for
________________________| high-performance interactive Macintosh graphics.
[e-mail]       | Available from mac.archive.umich.edu
- ----------------------| /mac/development/libraries/graphicelements2.sit.hqx

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Craig Jalkut)
Date: 22 May 1995 18:49:06 GMT
Organization: University of California, Santa Cruz


In <[e-mail]> Josh Brown <[e-mail]> writes:



>On 17 May 1995, Joel Quejada wrote:

>> What are the different techniques used for detecting collisions between
>> sprites? I use with a great deal of success the "union rect" technique,
>> where you compare two sprites' rects, if they overlap then you assume a
>> collision just happened.
>>
>> However, the technique above only works great for rectangular (or
>> mostly rectangular) sprites. How about for more irregular sprites?
>> What types of collision detection techniques are used for these?

Don't forget that your irregular shaped objects can be represented by
a number of regular rectangles.  With a humanoid character, for instance,
you could have a separate rectangle for head, torso, each arm, and each leg.

This allows you to have a fairly fast collision detection, and some
flexibility with shape. It also lets you check collisions differently if
your "sprite" changes form, as a humanoid would, when moving its arms.

--
 ____
/ /\ \  Daniel Craig Jalkut     "All I know is that I don't know nothing,
-/--\-  [e-mail]    and that's FINE" -- Operation Ivy
X____X  It's the job-seeking time of the year -- email for resume.


+++++++++++++++++++++++++++

>From [e-mail] (monsieur HAINEUX)
Date: Tue, 23 May 1995 18:25:34 -0700
Organization: Stripey Fruit CompuCo

In article <[e-mail]>, [e-mail] (Christer Ericson) wrote:
|   What Alex describes is the basic approach to pixel exact collision
|   detection which, while being "perfect", is slow as molasses. Much better
|   is the pixel-span approach to pixel exact collision detection: for each
|   scanline of the sprite you have two additional values, the offsets (relative
|   the left side of the bounding box) to the first and last non-transparent
|   pixel of that scanline. Checking whether two sprites collide now involves
|   an initial bounding box check, and if the bounding boxes overlap you
|   check if these spans overlap for the relevant scanlines. (If needed
|   keep a similar structure for each column of the sprite as well.)

In fact, this is how SectRgn works.

bill coderre

+++++++++++++++++++++++++++

>From [e-mail] (Ola Berg)
Date: 26 May 1995 16:38:06 GMT
Organization: Digit

Squareroots, sin() etc are slow but when using them as calculations for gfx,
then you can get enough accuracy by precalculate a number of sqr()'s and
sin()'s (and cos()'s ), and store them in an array. Then, instead of
calculating, just jump into the array! This is an old tech I know, but it
worked fine for CBM-64 and Sinclair SPECTRUM and it shouldn't be forgotten
even in these RISCy days right? ;-)

blsu!
Ola

+++++++++++++++++++++++++++

>From [e-mail] (monsieur HAINEUX)
Date: Tue, 30 May 1995 15:03:14 -0700
Organization: Stripey Fruit CompuCo

In article <[e-mail]>, [e-mail] wrote:
|   Squareroots, sin() etc are slow but when using them as calculations for gfx,
|   then you can get enough accuracy by precalculate a number of sqr()'s and
|   sin()'s (and cos()'s ), and store them in an array. Then, instead of
|   calculating, just jump into the array! This is an old tech I know, but it
|   worked fine for CBM-64 and Sinclair SPECTRUM and it shouldn't be forgotten
|   even in these RISCy days right? ;-)
|
|   blsu!
|   Ola

Not that I'm an expert, but on PowerPCs, it's actually faster to calculate
the SQRT than look it up. The mind boggles...

---------------------------

>From [e-mail] (Telesis North)
Subject: What is the Finder trying to tell me?
Date: Sat, 27 May 1995 23:33:41 GMT
Organization: noitazinagrO


Here's an odd one:

I've got an application that allows the user to drop files onto the
Finder. When a file is dropped somewhere else on the same volume,
including the trash, the Finder moves it as expected.

When the file is dropped onto a different volume, however, Finder
sends me the following AppleEvents (class/id):

   cwin / crea
   cwin / disp
   cwin / alrt

I can hazard a guess at what these might be, but are they actually
documented anywhere? I've looked through NIM and all the CD's
within easy reach, to no avail.

(System, BTW, is 7.5.1.)

Thanks,

--
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
"Baby, I feel fine... I'm pretty sure it's genuine.."  -- Tragically Hip

+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: Sun, 28 May 1995 10:47:33 -0400
Organization: Harvard University

In article <[e-mail]>, [e-mail] (Telesis
North) wrote:

> When the file is dropped onto a different volume, however, Finder
> sends me the following AppleEvents (class/id):
>
>    cwin / crea
>    cwin / disp
>    cwin / alrt
>
> I can hazard a guess at what these might be, but are they actually
> documented anywhere? I've looked through NIM and all the CD's
> within easy reach, to no avail.

As far as I can tell, these are not documented anywhere.  They are internal
Finder AppleEvents that are used to display a progress box and alerts, and
I don't think the Finder is supposed to send them to you at all.

The "cwin/crea" event tells you to create a progress box.  Since you don't
handle that event, the Finder thinks there is an error, so it immediately
sends a "cwin/disp" event to dispose of that box.  Then it sends a
"cwin/alrt" message to display an alert saying that there is an error of
type 1701 or something of that sort.

Here are the AppleEvent handlers that I use in Greg's Browser:

OSErr AEGetParamString ( AppleEvent *theAppleEvent, Str255 theString, long key )
{
   DescType typeCode;
   Size     actualSize;
   OSErr    theErr;

   theErr = AEGetParamPtr ( theAppleEvent, key, typeChar, &typeCode,
theString + 1, 255, &actualSize );
   theString[0] = actualSize;
   return theErr;
}

// cwin/crea
pascal OSErr BrowserApp::HandleCreate ( AppleEvent *theAppleEvent,
AppleEvent *reply,
                                    BrowserApp *theApp )
{
   Progress *theBox = new Progress ( 11237 );

   Str255      theString;
   OSErr    theErr;

   theErr = AEGetParamString ( theAppleEvent, theString, 0x00000005 );
   theBox->SetString ( 5, theString );

   theErr = AEGetParamString ( theAppleEvent, theString, 0x00000000 );
   theBox->SetString ( 0, theString );

   theErr = AEGetParamString ( theAppleEvent, theString, 0x00000001 );
   theBox->SetString ( 1, theString );

   theErr = AEGetParamString ( theAppleEvent, theString, 0x00000002 );
   theBox->SetString ( 2, theString );

   return noErr;
}

// cwin/cstr
pascal OSErr BrowserApp::HandleCString ( AppleEvent *theAppleEvent,
AppleEvent *reply,
                                    BrowserApp *theApp )
{
   Progress *theBox = ( Progress * ) GetWindow ( FrontWindow() );

   DescType typeCode;
   Str255      theString;
   Size     actualSize;
   OSErr    theErr;
   long     itemNum;

   if ( !theBox || !theBox->modal )
      return noErr;

   theErr = AEGetParamPtr ( theAppleEvent, keyDirectObject,
typeLongInteger, &typeCode,
                      &itemNum, 4, &actualSize );
   theErr = AEGetParamString ( theAppleEvent, theString );
   theBox->SetString ( itemNum, theString );

   return noErr;
}

// cwin/cbar
pascal OSErr BrowserApp::HandleCBar ( AppleEvent *theAppleEvent,
AppleEvent *reply,
                                  BrowserApp *theApp )
{
   Progress *theBox = ( Progress * ) GetWindow ( FrontWindow() );

   DescType typeCode;
   Size     actualSize;
   OSErr    theErr;
   long     max, val;

   if ( !theBox || !theBox->modal )
      return noErr;

   theErr = AEGetParamPtr ( theAppleEvent, 'maxb', typeLongInteger,
&typeCode, &max, 4, &actualSize );
   theErr = AEGetParamPtr ( theAppleEvent, 'valb', typeLongInteger,
&typeCode, &val, 4, &actualSize );
   theBox->SetBar ( (short)( max >> 8 ), (short)( val >> 8 ) );

   return noErr;
}

// cwin/disp
pascal OSErr BrowserApp::HandleDispose ( AppleEvent *theAppleEvent,
AppleEvent *reply,
                                    BrowserApp *theApp )
{
   Dialog   *d = ( Dialog * ) GetWindow ( FrontWindow() );

   if ( !d || !d->modal )
      return noErr;

   if ( d )
      delete d;

   return noErr;
}

// cwin/alrt
pascal OSErr BrowserApp::HandleAlert ( AppleEvent *theAppleEvent,
AppleEvent *reply,
                                   BrowserApp *theApp )
{
   DescType typeCode;
   Size     actualSize;
   OSErr    theErr;
   Str255      theString;
   long     alertType;
   short    dItem;

   theErr = AEGetParamPtr ( theAppleEvent, keyDirectObject,
typeLongInteger, &typeCode,
                      &alertType, 4, &actualSize );
   theErr = AEGetParamString ( theAppleEvent, theString );

   ParamText ( theString, nil, nil, nil );

   switch ( alertType ) {
      case 0 :
         dItem = Alert ( 6010, nil );
         break;
      case 1 :
         dItem = Alert ( 6010, nil );
         break;
      case 2 :
         dItem = Alert ( 6012, nil );
         break;
   }

   theErr = AEPutParamPtr ( reply, keyDirectObject, typeShortInteger,
                      &dItem, sizeof ( dItem ) );
   return noErr;
}

-- Greg Landweber
   [e-mail]
(author of "Greg's Buttons" and "Greg's Browser")

+++++++++++++++++++++++++++

>From [e-mail] (Bas A. Schulte)
Date: Sun, 28 May 1995 17:11:10 +0200
Organization: Models, Inc.

In article <[e-mail]>, [e-mail] (Telesis
North) wrote:

> When the file is dropped onto a different volume, however, Finder
> sends me the following AppleEvents (class/id):
>
>    cwin / crea
>    cwin / disp
>    cwin / alrt
>
> I can hazard a guess at what these might be, but are they actually
> documented anywhere?

I asked about this a while ago too, still don't have an answer. I peeked
at what the Greg's Browser does when you do this. It seems that when your
app is in the foreground, the Finder is instructing you to show a progress
window.

I still haven't figured out how to do that (don't know which ae's to
expect), but you could put the Finder in the foreground so it shows it's
own progress window. Try to drag a file to a different volume, and then
quickly click in the Desktop to see what I mean.

Regards,

Bas A. Schulte
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Telesis North)
Date: Sun, 28 May 1995 19:19:40 GMT
Organization: undecided

[e-mail] (Gregory D. Landweber) wrote:
>In article <[e-mail]>, [e-mail] (Telesis
>North) wrote:
>>    cwin / crea
>>    cwin / disp
>>    cwin / alrt
>>
>As far as I can tell, these are not documented anywhere.  They are internal
>Finder AppleEvents that are used to display a progress box and alerts, and
>I don't think the Finder is supposed to send them to you at all.

In article <[e-mail]>,
Bas A. Schulte <[e-mail]> wrote:
>I still haven't figured out how to do that (don't know which ae's to
>expect), but you could put the Finder in the foreground so it shows it's
>own progress window. Try to drag a file to a different volume, and then
>quickly click in the Desktop to see what I mean.

Thanks for the additional info. What I decided to do was look at the mouse
position of the drop (after TrackDrag() returns). If FindWindow() tells me
that it ended up somewhere else, I simulate a mouse click to bring that
window forward:

OSErr    SwitchToDest( DragReference dragRef)
// If the drag ended up in another process, fake some mouse events to
// switch  to it.
{
Point          pt;
WindowPtr      whichWin;
EvQElPtr       pEvQEl;
OSErr          errCode;

   if ( noErr == ( errCode = GetDragMouse( dragRef, &pt, NULL)) &&
        inDesk == FindWindow( pt, &whichWin))
   {
      if ( noErr == ( errCode = PPostEvent( mouseDown, 0L, &pEvQEl))) {
         pEvQEl->evtQWhere = pt;
         pEvQEl->evtQModifiers = 0;
         if ( noErr == ( errCode = PPostEvent( mouseUp, 0L, &pEvQEl))) {
            pEvQEl->evtQWhere = pt;
            pEvQEl->evtQModifiers = 0;
         }
      }
   }
   return errCode;
}

I realize that the mouse thing is a painful kludge; I'd rather use
SetFrontProcess(). Unfortunately, I can't find a way to translate that mouse
position (or the DropLocation) into a PSN. Ho, well.

I'm also somewhat annoyed that the Drag manager provides explicit support for
dragging files around, and even mentions that the Finder will move them - but
stops just short of documenting it completely. Perhaps this is a candidate
for DTS to answer in the Finder Q&A technote.

cheers,

--
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
"Mmmm... Soylent Green" -- Homer Simpson.

+++++++++++++++++++++++++++

>From [e-mail] (Bas A. Schulte)
Date: Thu, 01 Jun 1995 10:32:55 +0200
Organization: Models, Inc.

In article <[e-mail]>, [e-mail] (Telesis
North) wrote:

> Thanks for the additional info. What I decided to do was look at the mouse
> position of the drop (after TrackDrag() returns). If FindWindow() tells me
> that it ended up somewhere else, I simulate a mouse click to bring that
> window forward:
[...]
> I realize that the mouse thing is a painful kludge; I'd rather use
> SetFrontProcess(). Unfortunately, I can't find a way to translate that mouse
> position (or the DropLocation) into a PSN. Ho, well.
>
> I'm also somewhat annoyed that the Drag manager provides explicit support for
> dragging files around, and even mentions that the Finder will move them - but
> stops just short of documenting it completely. Perhaps this is a candidate
> for DTS to answer in the Finder Q&A technote.

Concluding the issue I'd say drag&drop with the HFSFlavor is quite
useless! Finder is only of the app's around, using inconsistent behaviour.
Do I have to special-case for each receiving app? MS Word probably handles
a drop quite differently, sending me yet other appleevents to show my
progress window (or would I need to become an OLE 2 server?).

Maybe I'll use the same method (posting a mousedown event to the receiving
app), what's a software company got to do?

One more for Greg: does the progress window you create after a cwin/crea
event have a 'cancel' button and if so, how do you handle that?

Regards, Bas.

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 2 Jun 1995 11:49:20 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Bas A. Schulte <[e-mail]> wrote:

>Concluding the issue I'd say drag&drop with the HFSFlavor is quite
>useless!

I wonder why everybody lets the Finder do the copy? I use GetDropLocation
to determine where the file should be put and I write it there directly
myself. I can display my own progress dialog if I wish to, and I can copy
a file much faster than the brain-dead Finder.

Anything I'm missing?




--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Telesis North)
Date: Sat, 3 Jun 1995 17:22:35 GMT
Organization: University of Toronto, Engineering Computing Facility

In article <3qmts0$[e-mail]>,
Francois Pottier <[e-mail]> wrote:
>I wonder why everybody lets the Finder do the copy? I use GetDropLocation
>to determine where the file should be put and I write it there directly

This is an approach I hadn't considered. If you do the copy yourself, does
the Finder clue into this and refrain from doing it as well? (And
presumably sending you weird AppleEvents, etc.)

As an aside, how do you tell it's the Finder you're dropping it on? (And
isn't having the source effectively accept the drop on behalf of the
destination a bit of an unconventional use of the model?)


--
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
CodeWarrior: because life is too short for MPW.

+++++++++++++++++++++++++++

>From [e-mail] (Telesis North)
Date: Tue, 6 Jun 1995 17:33:54 GMT
Organization: undecided


For any out there who are still interested, I came across this today in
the latest Drag & Drop release notes on CW6:

"If you drag a file to Finder version 7.1.3 using a flavorTypeHFS or
flavorTypePromiseHFS flavor, and that file is currently displayed in a
Finder window then that window will not be updated correctly.  Also if that
file is dragged to a different volume than the drop location than the
Finder will produce an error and the drag will usually fail.  These
problems also occur with System Software version 7.5.  These problems will
be fixed in a later version of system software."

I have no idea what "drag to a different volume than the drop (sic)
location" means, but this sounds suspiciously like an acknowledgement
of the weird-o AppleEvent problem.

- -
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
CodeWarrior: because life is too short for MPW.

---------------------------

>From [e-mail] (James Hague)
Subject: Why is the Prefererred Executable Format a big secret?
Date: 21 May 1995 21:02:47 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

In IM: PowerPC System software, it is stated that there are two types of
"containers" used for disk-based applications:  XCOFF and PEF.  IM goes
on to state that XCOFF is just a carry-over from Unix-based development
and that PEF is the format to use.  Furthermore, PEF is supposed to
result in much smaller files.

So where the heck is PEF documented?  Not in IM.  Do the MW compilers use
it?  I have done some digging and not been able to come up with anything.

(Note:  This is mostly for my own exploration, though I know other people
are looking for this information as well.  I was mostly planning on
picking apart a PPC application, just to see what information is in there
and how it is stored.  It bugs me that PEF is a big mystery even though
it is talked about in IM.)

James Hague
[e-mail]

+++++++++++++++++++++++++++

>From Michael Werts <[e-mail]>
Date: Sun, 21 May 1995 20:00:59 -0700
Organization: Cal State Long Beach

On 21 May 1995, James Hague wrote:

> So where the heck is PEF documented?  Not in IM.  Do the MW compilers use
> it?  I have done some digging and not been able to come up with anything.
>
> (Note:  This is mostly for my own exploration, though I know other people
> are looking for this information as well.  I was mostly planning on
> picking apart a PPC application, just to see what information is in there
> and how it is stored.  It bugs me that PEF is a big mystery even though
> it is talked about in IM.)
>
> James Hague
> [e-mail]
>
>

I agree absolutely.  Eight months ago I also poked around for this info.
I could not find it and the result was I switched my project to NT because
detailed information was available on the Portable Executable Format for
Win32.

I have the impression that Apple likes to force developer's to come to them
for information; at the same time I was looking for info on ASLM and had to
approach an Apple manager by email.

I do not like having to beg for information (of course, I am still lurking
around this group which shoulld give you an idea of how happy I am with NT).

MICHAEL WERTS -- [e-mail]
Computer Engineering Computer Science
California State University Long Beach


+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 26 May 1995 15:46:58 GMT
Organization: Apple Computer, Inc.

In article
<[e-mail]>, Michael
Werts <[e-mail]> wrote:

> > So where the heck is PEF documented?  Not in IM.  Do the MW compilers use
> > it?  I have done some digging and not been able to come up with anything.

Any PowerPC compiler has to generate PEF code, since that's the single
format for applications and libraries on PowerPC.

> I agree absolutely.  Eight months ago I also poked around for this info.
> I could not find it and the result was I switched my project to NT because
> detailed information was available on the Portable Executable Format for
> Win32.
> I have the impression that Apple likes to force developer's to come to them
> for information; at the same time I was looking for info on ASLM and had to
> approach an Apple manager by email.

Not really. It's just that it takes a long time to write decent
documentation, so not everything gets documented at the same rate. Things
like Mixed Mode and CFM are much more important for developers to know
about, so they get documented more quickly and in easily-available books.
PEF, on the other hand, is a format that really only needs to be exposed
to people building compilers/linkers or similar programming tools; not a
very large audience.
The question is what channel to go through to get whatever sketchy
documentation exists. Have you tried writing to
[e-mail]? I've sent out some e-mail around here and
I'll post the answer if I get one.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

                LLAMA: NO FEAR OF SPIKES

+++++++++++++++++++++++++++

>From Alan Harper <[e-mail]>
Date: 28 May 1995 10:09:47 GMT
Organization: Eclectus

In article <[e-mail]>
Jens Alfke, [e-mail] writes:
>PEF, on the other hand, is a format that really only needs to be exposed
>to people building compilers/linkers or similar programming tools; not a
>very large audience.
>

For what it's worth, I am just working on an app, but I needed to
generate an xcoff segment which I use as a data store and a jump
table. Finding out the xcoff file format wasn't easy since Apple
supplies no documentation (and figuring out which relocations
Apple & MW supported was pure experimentation). I've seen about
5 other posts on c.s.m.p.etc asking for xcoff documentation, so
I do think that library/executable file formats are things many
programmers need to know about.

So, please post info if you find any documentation on PEF.

- -------------------------------------------------
Alan Harper                77 Jack London Sq, Ste H
[e-mail]           Oakland, CA 94607
                           510/444-6605

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 28 May 1995 23:09:49 GMT
Organization: Dartmouth College, Hanover, NH

In article <3q9i5b$[e-mail]>
Alan Harper <[e-mail]> writes:
> In article <[e-mail]>
> Jens Alfke, [e-mail] writes:
> >PEF, on the other hand, is a format that really only needs to be exposed
> >to people building compilers/linkers or similar programming tools; not a
> >very large audience.
> >
>
> For what it's worth, I am just working on an app, but I needed to
> generate an xcoff segment which I use as a data store and a jump
> table. Finding out the xcoff file format wasn't easy since Apple
> supplies no documentation (and figuring out which relocations
> Apple & MW supported was pure experimentation). I've seen about
> 5 other posts on c.s.m.p.etc asking for xcoff documentation, so
> I do think that library/executable file formats are things many
> programmers need to know about.
>
> So, please post info if you find any documentation on PEF.
>
> ---------------------------------------------------
> Alan Harper                77 Jack London Sq, Ste H
> [e-mail]           Oakland, CA 94607
>                            510/444-6605

The xcoff format is merely a temporary format used by PPCC and some
other compilers, and is read by older versions of the two-mac debugger.
 I think that more recent compilers can link directly to PEF, and the
two-mac debugger doesn't need the xcoff file any more, either.  PEF is
very similar to xcoff, but I can see why it might be difficult to get
xcoff docs since it isn'tthe interesting format.

PEF isn't that difficult to figure out, either.  Grab your copy of the
dumppef MPW tool and a bunch of PEF apps, then compare and contrast
dumppef's output on these files.  The labels that dumppef uses are very
informative (especially in the latest version of dumppef).

Did you ever hack games file when you were a kid?  ;-)  That's the mind
set you need.

Mark.

+++++++++++++++++++++++++++

>From [e-mail] (James Hague)
Date: 29 May 1995 16:54:14 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

[e-mail] <[e-mail]> wrote:
>
>PEF isn't that difficult to figure out, either.  Grab your copy of the
>dumppef MPW tool and a bunch of PEF apps, then compare and contrast
>dumppef's output on these files.  The labels that dumppef uses are very
>informative (especially in the latest version of dumppef).
>
>Did you ever hack games file when you were a kid?  ;-)  That's the mind
>set you need.

It's appalling that Apple forces people to take this route, though.

Near as I can figure, from email I have received, Apple is forcing
developers to pay some ridiculous amount to get information on the inner
workings of PowerPC system software.  What's presented in the IM volume
of the same name is vague, misleading, and full of holes.

James Hague
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (The Weasel)
Date: 31 May 1995 00:22:15 GMT
Organization: Computer Science Department, Stanford University.

>>PEF isn't that difficult to figure out, either.  Grab your copy of the
>>dumppef MPW tool and a bunch of PEF apps, then compare and contrast
>>dumppef's output on these files.  The labels that dumppef uses are very
>>informative (especially in the latest version of dumppef).

While I have not seen the very latest version of dumppef, you might want
to try yadp from jasik instead. I think that the format that it
dumps things is a bit nicer than dump pef.

On figuring it all out by yourself, some parts of the PEF format
are sort of weird even with the docs supplied by Apple. At least
I thought so :-).

Peter
--
ObURL:       <a href="http://xenon.stanford.edu/~pchang/bhh.html">
ObQuote:     Do not do unto others as you would they should do unto you.
             Their tastes may not be the same. -- GBS

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 31 May 1995 13:33:53 GMT
Organization: Dartmouth College, Hanover, NH

In article <3qgcrn$[e-mail]>
[e-mail] (The Weasel) writes:
> >>PEF isn't that difficult to figure out, either.  Grab your copy of the
> >>dumppef MPW tool and a bunch of PEF apps, then compare and contrast
> >>dumppef's output on these files.  The labels that dumppef uses are very
> >>informative (especially in the latest version of dumppef).
>
> While I have not seen the very latest version of dumppef, you might want
> to try yadp from jasik instead. I think that the format that it
> dumps things is a bit nicer than dump pef.
>
> On figuring it all out by yourself, some parts of the PEF format
> are sort of weird even with the docs supplied by Apple. At least
> I thought so :-).

The latest version is much better than previous version, although I
have not seen yadp to compare.  One nice thing the new version will do
is dump an entire PIData section annotated with the packing
instructions.  Oh, how I wish I had this when I was trying to figure
out the packing stuff!

I thought PEF was pretty straightforward, after I knew what everything
was for, of course.  Maybe not having the Apple docs was a good thing
;-)

Mark.

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: 31 May 1995 16:15:44 GMT
Organization: Ibex Productions

In article
<[e-mail]> Michael
Werts, [e-mail] writes:
>I have the impression that Apple likes to force developer's to come to them
>for information; at the same time I was looking for info on ASLM and had to
>approach an Apple manager by email.
>

Why not just check on the normal ftp sites or on the developer disc for
the ASLM info?

Also, there's some kind of hacked PEF format description floating
around. I know it's up on Compuserve; it might be on info-mac by
now.

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Tue, 6 Jun 1995 22:58:08 GMT
Organization: Apple Computer, Inc.

In article <3q9i5b$[e-mail]>, Alan Harper <[e-mail]> wrote:

> For what it's worth, I am just working on an app, but I needed to
> generate an xcoff segment which I use as a data store and a jump
> table. Finding out the xcoff file format wasn't easy since Apple
> supplies no documentation (and figuring out which relocations
> Apple & MW supported was pure experimentation). I've seen about
> 5 other posts on c.s.m.p.etc asking for xcoff documentation

XCOFF comes, I believe, from the Unix world. It's not an Apple-invented
format. The main reason it's used on the Mac at all is that it's the
object code format that the RS/6000 compilers generate, and all the
original PPC code was cross-compiled on those systems, before the days of
PPCC and CodeWarrior.
Unix is generally pretty self-documenting, so there should be XCOFF docs
available online on various Unix systems... log into an RS/6000 sometime
and try "man xcoff".


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

                LLAMA: NO FEAR OF SPIKES

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Melmon)
Date: Tue, 6 Jun 1995 23:29:57 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

> In article <3q9i5b$[e-mail]>, Alan Harper <[e-mail]>
wrote:
>
> > For what it's worth, I am just working on an app, but I needed to
> > generate an xcoff segment which I use as a data store and a jump
> > table. Finding out the xcoff file format wasn't easy since Apple
> > supplies no documentation (and figuring out which relocations
> > Apple & MW supported was pure experimentation). I've seen about
> > 5 other posts on c.s.m.p.etc asking for xcoff documentation
>
> XCOFF comes, I believe, from the Unix world. It's not an Apple-invented
> format. The main reason it's used on the Mac at all is that it's the
> object code format that the RS/6000 compilers generate, and all the
> original PPC code was cross-compiled on those systems, before the days of
> PPCC and CodeWarrior.
> Unix is generally pretty self-documenting, so there should be XCOFF docs
> available online on various Unix systems... log into an RS/6000 sometime
> and try "man xcoff".

XCOFF (Extended Common Object File Format - or something) is an
extension (go figure) to the Common Object File Format of Unix
geekdom.  Relevent for the reasons Jens states:  that's what xlc
spit out (or what xlc and ld spit out).  PPCLink used to spit
out XCOFF, subsequently converted to PEF (Power Executable Format,
not Preferred) by MakePEF.  The MakePEF step has been eliminated
in the most recent version of PPCLink (shipping on ETO 17).  PPCLink
generates PEF directly.

As for the documentation of PEF, the Dude to Contact is probably
Jordan Mattson at MATTSON1 (AppleLink).  For XCOFF documentation,
man xcoff won't cut it.  The format is documented in IBM's
"AIX Files Reference."  The manual number I have is GC23-2200-03.
That's for AIX 3.2, they're now on 4.x I believe.  Those with
RS/6000's can check on Info Explorer, in the Files book.

--
*X*
Splatasha, Queen of the Damned (Vanishing Sig)

---------------------------

End of C.S.M.P. Digest
**********************